builder.Build() fails to construct GatewayLlmExecutionService during DI validation because it has two public constructors that can both be resolved by the current container#46
Open
geffzhang wants to merge 4 commits intoclawdotnet:mainfrom
Conversation
GatewayLlmExecutionService is now registered directly by implementation type, and the container scans all its public constructors. The source code still retains two constructor paths: one using ConfiguredModelProfileRegistry + IModelSelectionPolicy, and the other using LlmProviderRegistry. Currently, both sets of dependencies are registered in IServiceCollection, and PromptCacheCoordinator and PromptCacheWarmRegistry are also registered. As a result, both public constructors meet the resolution criteria, and the ServiceProvider cannot determine which one to choose, so it throws an AmbiguousConstructorException. The root cause is not in Program.cs, but rather that when the old and new construction methods coexist, the old backward-compatible constructor remains exposed to DI. Feasible fix: Make DI see only one constructor. Preferably change the two backward-compatible constructors based on LlmProviderRegistry to private/internal or remove them, keeping only the public constructor based on ConfiguredModelProfileRegistry + IModelSelectionPolicy.
Changes:
Added an initial handshake frame : connected\n\n uniformly to both SSE endpoints, ensuring the response starts immediately.
Extracted the SSE write logic into a private helper method to reduce duplication.
Catch and ignore OperationCanceledException when ctx.RequestAborted is triggered, preventing normal client disconnections from being treated as unhandled exceptions.
Affected endpoints:
/admin/channels/{channelId}/auth/stream
/admin/channels/whatsapp/auth/stream
Contributor
Author
|
fix #47 |
Update tests to instantiate ConfiguredModelProfileRegistry and DefaultModelSelectionPolicy and pass them into GatewayLlmExecutionService (reflecting the new model-profile-based constructor), plus related using and variable adjustments across GatewayAdminEndpointTests, GatewayWorkersTests, and ModelProfileSelectionTests. Remove the custom removal of Avalonia DataAnnotations validation from App.axaml.cs (clean up/usings and keep normal initialization). Bump Avalonia package versions to 11.3.13 in the Companion project and add Tmds.DBus.Protocol (0.21.3). These changes adapt tests and the app to the updated execution API and dependency updates.
Add overloads to GatewayLlmExecutionService that accept an LlmProviderRegistry (and related simple ctor variants) and route through a new private ctor that accepts CompatibilityServices created via CreateCompatibilityServices. This centralizes compatibility service creation and simplifies DI. Update ModelProfileSelectionTests to construct and register a LlmProviderRegistry and pass it to the service (also add a Models config block), replacing the previous direct use of ConfiguredModelProfileRegistry and DefaultModelSelectionPolicy.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
GatewayLlmExecutionService is now registered directly by implementation type, and the container scans all its public constructors. The source code still retains two constructor paths: one using ConfiguredModelProfileRegistry + IModelSelectionPolicy, and the other using LlmProviderRegistry. Currently, both sets of dependencies are registered in IServiceCollection, and PromptCacheCoordinator and PromptCacheWarmRegistry are also registered. As a result, both public constructors meet the resolution criteria, and the ServiceProvider cannot determine which one to choose, so it throws an AmbiguousConstructorException. The root cause is not in Program.cs, but rather that when the old and new construction methods coexist, the old backward-compatible constructor remains exposed to DI. Feasible fix: Make DI see only one constructor. Preferably change the two backward-compatible constructors based on LlmProviderRegistry to private/internal or remove them, keeping only the public constructor based on ConfiguredModelProfileRegistry + IModelSelectionPolicy.
Type of Change
Checklist
dotnet test)Screenshots (if applicable)
[Add screenshots for UI/UX changes]
Benchmarks (if applicable)
[Did this change affect performance? Provide benchmark results.]